AWS SUMMIT 2026 · GENAI / MLOPS / AGENTOPS

AWS Summit
AI 시스템 운영 구조 정리

오늘 배운 내용은 AWS 서비스 이름을 외우는 것이 아니라, 데이터 → 모델 → 에이전트 → 관측성 → 비용 최적화가 어떻게 하나의 운영 구조로 연결되는지 이해하는 것이 핵심이다.

01 오늘의 큰 흐름
AI를 잘 쓰기 위해서는 모델만 좋은 것이 아니라, 데이터를 잘 관리하고, 운영 과정을 자동화하며, 비용과 품질을 지속적으로 관찰할 수 있는 구조가 필요하다.
데이터 수집/정제 Data Quality MLOps GenAI / Agent Observability
02 핵심 키워드 요약
KeywordMeaning
Amazon Bedrock여러 생성형 AI 모델을 API로 사용할 수 있게 해주는 AWS GenAI 플랫폼
SageMaker머신러닝 모델을 만들고, 학습시키고, 배포하고, 운영하는 ML 플랫폼
MLOpsML 모델을 안정적으로 배포·운영·모니터링·개선하기 위한 체계
AWS Glue여러 데이터 소스의 데이터를 수집·변환·정리하는 ETL 데이터 통합 서비스
Data Quality데이터가 정확하고, 누락되지 않고, 일관성 있게 유지되는지 검증하는 것
Multi-Agent여러 AI Agent가 역할을 나눠 협업하는 구조
Agent ObservabilityAgent가 어떤 판단과 도구 호출을 했는지 추적하고 관찰하는 운영 체계
03 Amazon Bedrock
WHAT IS BEDROCK?

Bedrock은 개발자가 직접 모델 서버를 운영하지 않아도, 여러 Foundation Model을 AWS 환경 안에서 API 형태로 호출할 수 있게 해주는 서비스다.

Model API AWS Managed GenAI
핵심 역할
  • 다양한 Foundation Model 선택
  • 모델 서버 없이 API 호출
  • AWS 보안·권한 체계와 연계
  • Agent, 지식 기반, 외부 도구와 연결
쉽게 말하면, Bedrock은 이미 잘 만들어진 AI 모델을 AWS 안에서 안전하게 골라 쓰게 해주는 플랫폼이다.
04 SageMaker & MLOps
BEDROCK VS SAGEMAKER
구분BedrockSageMaker
목적생성형 AI 모델 사용ML 모델 직접 개발·학습·배포
관리AWS/모델 제공사 관리사용자가 세밀하게 관리
적합빠른 GenAI 기능 구현커스텀 모델·튜닝·운영
MLOPS가 필요한 이유
  • 데이터가 계속 바뀐다.
  • 사용자 행동과 입력 패턴이 바뀐다.
  • 모델 성능이 시간이 지나며 떨어질 수 있다.
  • 따라서 배포 후에도 모니터링과 재학습이 필요하다.
MLOps 관리 대상
데이터 버전 → 모델 버전 → 학습 파이프라인 → 배포 파이프라인 → 모니터링 → 재학습
05 AWS Glue & Data Quality
AWS GLUE

Glue는 여러 곳에 흩어진 데이터를 분석하기 좋은 형태로 수집하고 변환하고 정리하는 데이터 통합 서비스다.

Extract Transform Load
DATA QUALITY
  • Null 체크: 고객 ID가 비어 있지 않은가?
  • 범위 체크: 값이 정상 범위 안에 있는가?
  • 중복 체크: 같은 주문 ID가 반복되지 않는가?
  • 형식 체크: 이메일, 날짜 형식이 맞는가?
  • 참조 무결성: 연결된 데이터가 실제로 존재하는가?
AI와 ML 시스템은 데이터에 크게 의존한다. 잘못된 데이터가 들어가면 좋은 모델도 잘못된 결과를 낸다.
06 Multi-Agent 구조
PLANNER

전체 목표를 분해하고 작업 순서를 설계한다.

RESEARCH

필요한 정보와 문서를 검색하고 근거를 수집한다.

CODING / ACTION

코드 작성, API 호출, 실제 실행 작업을 담당한다.

REVIEW

결과의 정확성, 누락, 안정성을 검토한다.

COST

모델 호출 비용과 리소스 사용량을 확인한다.

OPS

배포와 운영 상태, 장애 가능성을 점검한다.

Multi-Agent의 본질은 “AI를 많이 붙이는 것”이 아니라, 역할과 책임을 나눠 품질·비용·실패 지점을 관리하기 쉽게 만드는 것이다.
07 비용 · 응답 시간 · 품질의 균형

Cost

모든 요청에 고성능 모델을 쓰면 구현은 단순하지만 비용이 커진다.

Latency

여러 Agent로 쪼개면 비용은 줄어도 호출 단계가 늘어나 응답 시간이 증가할 수 있다.

Quality

저비용 모델만 쓰면 품질 저하, 재시도, 검증 비용이 오히려 늘 수 있다.

기존 방식
모든 요청 → 고성능 모델 → 응답
개선 방식
분류 → 검색 → 요약 → 복잡 추론 → 최종 검증
비용 최적화의 핵심은 싼 모델을 쓰는 것이 아니라, 쉬운 일은 저비용 모델에게, 어려운 일은 고성능 모델에게 맡기는 구조를 만드는 것이다.
08 Agent Observability
기존 API 흐름
요청 → 로직 실행 → 응답
Agent 실행 흐름
요청 → 의도 파악 → 계획 수립 → 도구 선택 → 외부 API 호출 → 중간 판단 → 최종 응답
관찰 항목확인해야 하는 것
Prompt사용자가 어떤 요청을 했는가?
PlanAgent가 어떤 계획을 세웠는가?
Tool Call어떤 도구/API를 호출했는가?
Latency어느 단계에서 오래 걸렸는가?
Cost어느 단계에서 비용이 많이 발생했는가?
Error어떤 모델/도구 호출에서 실패했는가?
Output Quality최종 응답이 정확하고 유용한가?
Agent 운영에서는 서버가 정상인지뿐 아니라, Agent가 정확하고 안전하고 유용하게 행동했는지까지 관찰해야 한다.
09 최종 인사이트
DATA FIRST

데이터 품질이 낮으면 모델 성능과 AI 답변의 신뢰도도 낮아진다.

OPS MATTERS

모델은 만들고 끝나는 것이 아니라 운영하면서 성능과 비용을 계속 관리해야 한다.

TRACE EVERYTHING

Agent는 판단과 도구 호출이 복잡하므로 실행 과정을 추적할 수 있어야 한다.

생성형 AI 시대의 핵심은 모델을 잘 쓰는 것뿐만 아니라, 데이터부터 운영, 비용, 품질, 관찰 가능성까지 전체 구조를 설계하는 것이다.